Generating an Ambulatory Surgical Center (ASC) Electronic Medical Record (EMR)

ABSTRACT

A computer-implemented method comprises: establishing, over a private network in an ambulatory surgical center (ASC), a communication channel between a medical device in the ASC and an ASC integration system that is connected to the Internet; receiving, by the established communication channel over the private network, real-time medical information from the medical device, during performance of a surgical procedure at the ASC; applying one or more notification rules to the received real-time medical information to detect the occurrence of a triggering event; determining, from the one or more notification rules, one or more entities to contact regarding the triggering event, with the one or more entities having one or more devices that are unconnected to the private network; and transmitting, by the ASC system over the Internet, one or more notification messages to the one or more devices that are unconnected to the private network.

BACKGROUND

Medical forms are used to collect data and information regarding apatient's symptoms and conditions.

SUMMARY

In one implementation, a computer-implemented method comprises:establishing, over a private network in an ambulatory surgical center(ASC), a communication channel between a medical device in the ASC andan ASC integration system that is connected to the Internet, with themedical device being restricted to communication over the privatenetwork; receiving, by the established communication channel over theprivate network, real-time medical information from the medical device,during performance of a surgical procedure at the ASC; applying one ormore notification rules to the received real-time medical information todetect the occurrence of a triggering event; determining, from the oneor more notification rules, one or more entities to contact regardingthe triggering event, with the one or more entities having one or moredevices that are unconnected to the private network; and transmitting,by the ASC system over the Internet, one or more notification messagesto the one or more devices that are unconnected to the private network.A system of one or more computers can be configured to performparticular operations or actions by virtue of having software, firmware,hardware, or a combination of them installed on the system that inoperation causes or cause the system to perform the actions. One or morecomputer programs can be configured to perform particular operations oractions by virtue of including instructions that, when executed by dataprocessing apparatus, cause the apparatus to perform the actions.

The actions include receiving, from an external device, a request toschedule the surgical procedure with the ASC; receiving, from theexternal device, a Consolidated Clinical Document Architecture (CCDA)record that includes first medical information for a patient for whomthe surgical procedure is being scheduled; receiving, from anotherexternal device, second medical information for the patient; detecting aconflict between the first medical information and the second medicalinformation; and prompting a user for information to resolve theconflict. The actions include transforming the first and second medicalinformation into an ASC EMR by generating a data record that includesthe second medical information and attaching the generated data recordto the first medical record; executing a rules engine against contentsof ASC EMRs to determine whether the ASC EMRs comply with one or moregovernmental regulations for ASC EMRs; and receiving, from an electronicdevice in an operating room over a private network, real-time operatingroom information; and adding the real-time operating room information tothe ASC EMR. The second medical information is retrieved from a medicalinstrument system that is configured to administer one or medicalinstruments and collect results of those medical instruments. Theactions include generating information indicative of an appointment toperform the surgical procedure; and defining, for the appointment, oneor more roles of service providers in the ASC with regards to thesurgical procedure, with a role specifying one or more types ofinformation that a particular type of service provider is responsiblefor inputting into the ASC system. The actions include receivinginformation that is input to the system from a service provider assignedto a specific role, with the received information including a personalidentification number; and confirming that the personal identificationnumber matches an authorized personal identification number of a userwho is authorized to perform the role and to input a type of informationto be completed by an entity in the assigned role. The actions includeautomatically triaging, by the ASC system, intake of a patient for whomthe surgical procedure is performed by performing operations comprising:generating data for a graphical user interface that displays consentforms and medical information for the patient, with the medicalinformation being collected from a plurality of different data sources.The actions include synchronizing, by the ASC system, the real-timemedical information with other medical information included in a datarepository of the ASC system. Synchronizing comprises: updating a datarecord in the data repository with the real-time medical information.

All or part of the foregoing may be implemented as a computer programproduct including instructions that are stored on one or morenon-transitory machine-readable storage media and/or one or moremachine-readable hardware storage devices that are executable on one ormore processing devices. All or part of the foregoing may be implementedas an apparatus, method, or electronic system that may include one ormore processing devices and memory to store executable instructions toimplement the stated functions.

The details of one or more implementations are set forth in theaccompanying drawings and the description below. Other features,objects, and advantages will be apparent from the description anddrawings, and from the claims.

BRIEF DESCRIPTION OF THE FIGURES

FIGS. 1-7 and 9-13 are screen images of graphical user interfacesgenerated by a system for generating an ASC EMR.

FIGS. 8, 16 and 17 are flow charts of example processes for generatingan ASC EMR.

FIG. 14 is a diagram of a system for generating an ASC EMR.

FIG. 15 is a block diagram of components of a system for generating anASC EMR.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Referring to FIG. 1, graphical user interface 100 displays informationpertaining to a patient of an ambulatory surgical center (ASC).Generally, ASCs are medical facilities that specialize in electivesame-day or outpatient surgical procedures. A system consistent withthis disclosure aggregates medical information for use in an ASC, aswell as facilitating ASC operation. Graphical user interface 100includes menu 102 to enable a view to access various types ofinformation for the ASC, including, medical records, a patient history,consent form, documentation, attachments, chart notes and a reportbuilder. Graphical user interface 100 also includes portions 104, 106,108 to provide the viewer with vital information, medication informationand allergy information, respectively. Graphical user interface 100 alsoincludes stage section 110 with controls 110 a-110 e. Selection of oneof controls 110 a-110 e causes portions 104, 106, 108 to be updated todisplay information that associated with the particular stage (e.g.,stage of a medical procedure) for the selected control. For example,when a user selects controls 110 a, portions 104, 106, 108 are updatedto display vital information, medication information and allergyinformation, respectively, as of pre-admission.

Referring to FIG. 2, graphical user interface 200 displays details of amedical record, e.g., for a patient of the ASC. Graphical user interface200 includes portions 202, 204, 206, 208, 210, 212 to displayinformation indicative of referring doctor details, general notes,pending alerts, patient details, physical exams, and X-rays,respectively. In an example, the system (that generates graphical userinterface 200) receives the medical record information from aConsolidated Clinical Document Architecture (CCDA) document that is sentfrom a CCDA system. In this example, physical exam portion 210 displaysinformation indicative of which physical exams the patient has alreadyhad performed. Portion 210 allows for a manual override by enabling auser to select one of the physical exam types, e.g., to specify that theuser has had that type of physical exam.

Referring to FIG. 3, graphical user interface 300 displays patienthistory information, e.g., using information that is collected from theCCDA system, information that is collected from the ASC system describedherein, or that is collected from a medical instrument system (forsending medical questionnaires and instruments to patient. Graphicaluser interface 300 includes timeline 302 to display discrete intervalsat which the questions of a particular medical instrument are asked to apatient, and corresponding responses. Graphical user interface 300includes controls 304 a, 304 b, 304 c and 304 d to enable filtering ofthe patient history. For example, control 304 a enables a user to viewall of the answers. Control 304 b enables a user to view “moderate”answers to questions, e.g., those answers that exceed a specifiedthreshold that represents a moderate nature. Control 304 c enables auser to view extreme answers to questions, e.g., those answers thatexceed a specified threshold that represents an extreme nature. Control304 d enables a user to view unanswered questions. Graphical userinterface 300 also includes controls 306 a, 306 b to able a user to addnotes to the answers and to edit answers to questions, respectively.

Referring to FIG. 4, graphical user interface 400 displays variousconsent forms to a viewer. For example, graphical user interface 400displays consent form portions 402, 404. Consent form portions 402, 404each display information specifying individuals who are required to signthe consent form. For example, consent form portion 402 includesrequired individual information 402 a, 402 b specifying that a patientand a witness are each required to sign off on the consent form. Consentform portion 404 includes required individual information 404 a, 404 b,404 c specifying that a doctor, a patient and a witness are eachrequired to sign off on the consent form. Selection of portions 402, 404causes a display of the appropriate consent form.

Referring to FIG. 5, graphical user interface 500 allows a user to inputvarious documentation, e.g., following a medical procedure. Suchprocedure can include an anesthesia procedure. Graphical user interface500 includes fields 502, 504, 506, 508 for the input of thisdocumentation information. In an example, fields 502, 504, 506, 508 areauto-populated, e.g., based on information received in a CCDA documentand/or other collected information. The values of fields 502, 504, 506,508 can also be manually overwritten, e.g., to be updated.

In an example, the system synchronizes the data in real-time frommultiple data sources. In this example, some of the data may be inconflict, e.g., the same data field may have differing, conflictingvalues. In this example, the system performs conflict resolution, e.g.,based on date and time in which the most recent data values overrideless recent data values. Following conflict resolution, an alert isdisplayed (via the system) that shows that various data values aremodified.

Referring to FIG. 6, graphical user interface 600 provides for medicalreconciliation (e.g., based on detection of a conflict among values indata fields). After resolution, there is an alert that shows that thepage has been modified. Graphical user interface 600 includes portions602, 604 that specify which types of medical information need to bereconciled. For example, portion 602 specifies that medicationallergies/reactions need reconciliation, e.g., by prompting the user tospecify whether there is a medication reaction/allergy to latex or othermaterials. For example, a CCDA record may indicate that a patient doesnot have an allergy to latex. Another medical record may indicate thatthe patient does have an allergy reaction to latex. Accordingly, thereis a conflict regarding whether the patient has an allergic reaction tolatex and the patient or another user is prompted to resolve theconflict, e.g., by providing reconciliation information into graphicaluser interface 600.

In this example, portion 604 prompts the user to reconcile whether apatient is taking home medications (e.g., via a yes/no field). Followingthe input of the reconciliation information, graphical user interface600 prompts various entities for their signature, e.g., to input thereconciliation information. Once the reconciliation information is inputinto the system, the reconciliation information overrides all otherconflicting information for a particular field.

In this example, portions 606, 608, 610 require signatures from variousentities (i.e., a pre-OP nurse, a discharge nurse and a patient), priorto entering the reconciliation information into the system. Thesevarious signatures are required to ensure the authenticity and validityof the reconciliation information that is being input into the system.

Referring to FIG. 7, the ASC system provides for per appointment roles,e.g., for the various types of service providers. In an example, for aparticular appointment, the system sets up various “roles”—assignmentsto be completed by pre-specified types of service providers. In thisexample, for a particular appointment and/or type of procedure, variousservice providers will have various, specified types of roles, e.g., arole of filling out a pre-operative admission record, a role ofadministering intravenous access, a role of planning discharge, a roleof determining nursing and diagnosis roles, and a role of filling out apreoperative checklist. In this example, a particular type of serviceprovider is assigned to a particular role. On the backend, a databaserecord (in a database) in updated with information specifying which typeof service provider is assigned to the various roles. The informationspecifying the assigned type of service provider is linked to otherinformation specifying the names of service providers of the specifiedtype, as shown in the below Table 1.

TABLE 1 Type Role of Service Provider Valid PINS Complete Pre-OperativePre-Op Nurse; Pre-Op Nurse Signature Checklist OR Circulator (1234,1245) OR Circulator Signature (1244, 1256)

As shown in the above Table 1, an example data base record specifies arole of completing a pre-operative checklist. The database record alsospecifies that two types of service providers (e.g., a pre-op nurse andan operating room (OR) circulator) are authorized to fill out andcomplete the pre-op checklist. The database record also specifies validpersonal identification numbers (PINS) for the service providers thatare authorized to complete the role, e.g., by filling out the pre-opchecklist. In order to enter and save the information entered into apre-op checklist, a PIN number is entered. The system verifies if theentered PIN matches one of the pre-authorized pins that are associatedwith the role, e.g., as shown in the above Table 1.

In the example of FIG. 7, graphical user interface 700 includes roleinformation 702, 704, 706, 708, 710 that is indicative of the variousroles that a service provider may provide during an appointment. In anexample, role information 702 specifies types of information that is tobe entered by a service provider fulfilling a specific role. Forexample, role information 710 specifies that a pre-operative checklistis to be completed by a pre-operative nurse and an OR circulator. Roleinformation 710 includes fields 712 for input and/or selection ofrequired information. Upon completion of fields 712, the user completingfields 712 enters his/her signature (e.g., an assigned PIN). In thisexample, only pre-op nurses and OR circulators may enter informationinto fields 712. Graphical user interface 700 also includes PIN fields714, 716 for entry of PINS of service providers of the authorized type.Prior to saving the information entered into fields 712, the systemverifies that the PINS entered into PIN fields 714, 716 matches thevalid pins specified in the data record, e.g., as shown in the aboveTable 1, thereby verifying that only authorized personally in theirassigned roles are completing the pre-operative checklist.

Referring to FIG. 8, process 800 is performed to integrate a CCDA recordwith an ASC system 803 described herein. In operation, a client device801 accesses and downloads (802) a CCDA record, e.g., from an externaldatabase, from a hospital, and so forth. The client device 801 uploads(804) the CCDA record to the ASC system 803. The ASC system 803validates (806) the format of the CCDA record, e.g., to ensure that thefields in the CCDA record are accessible and/or are formatted inaccordance with predefined standards. The ASC system 803 duplicates(808) the CCDA record for storing in a database of the ASC system 803and displays (810) a confirmation screen to notify the user of theduplication. In an example, the duplicated record is a new record forthe ASC system. The ASC system 803 creates (812) demographic informationfor the newly created record, e.g., using responses to questions inother medical instruments that the ASC system collects or otherwise hasaccess to. In an example, the ASC system 803 identifies medicalquestionnaires or instruments that are completed by a particularpatient, based on patient name, a social security number or otheridentifying information. The ASC system 803 identifies a match betweenthe particular patient and a patient identified in a CCDA record basedon name matching or based on matching the other identifying informationincluded in the CCDA record and the medical questionnaire. Based on thematched records, the ASC system 803 attaches the CCDA document to thepatient by generating a database pointer between the CCDA record and theother collected records and instruments for the patient. Followinglinking of the CCDA record to the other records and instruments, thepatient exists in the ASC system (e.g., the patient is represented byone or more database records in the ASC system).

Referring to FIG. 9, graphical user interface 900 allows for importationof patient data, e.g., via a CCDA document. In this example, graphicaluser interface 900 is displayed on a client device that is configuredfor integration with one or more external systems. In this example, theclient device is a terminal of the the ASC system. Graphical userinterface 900 includes clinic field 904 for user selection of one ormore clinics that are pre-configured for communication with the clientdevice. Graphical user interface 900 also includes file control 902, forthe user to select which CCDA file they want to import from the externalsystem.

Graphical user interface 900 also includes patient identifiable control906 for the user to specify whether the user wants to importidentifiable patient data or de-identifiable patient data. If the userwants to input de-identifiable patient data, graphical user interface900 includes control 908 for the input of a user ID that may be used toidentify the patient, in lieu of other identifying information. In thisexample, the other database records that are already collected by theASC system also include the patient ID, e.g., thereby enabling the ASCsystem to match the CCDA record with other records.

Graphical user interface 900 also includes name fields 910, 912 forentry of first and last name information, respectively. In this example,the first and last name information is used for integrating the CCDAdocument with other documents that are stored in or otherwise accessibleby the ASC system, e.g., based on matching of names among the records.

Referring to FIG. 10, graphical user interface 1000 displays varioustypes of real-time vitals information over a period of time, e.g., basedon the real-time monitoring of data. In this example, graphical userinterface 1000 includes control 1002, selection of which causes thesystem to re-take a reading of the relevant vital information and toupdate the graph accordingly. In this example, a user get set athreshold for a type of information (e.g., that is being charted). Whena value for the type of information exceeds the threshold, the system isconfigured to display an alert for the user. Graphical user interface1000 also includes control 1004 that represents a timer that specifieshow frequently data is being collected and how frequently the graphdisplayed in FIG. 10 is being updated.

In an example, an emergency room does not have Internet access, forsecurity and confidentiality reasons. In this example, a virtual privatenetwork (VPN) is established between the ASC system and the monitoringdevices in the emergency room, e.g., to enable the real timetransmission of health date from the emergency room devices to the ASCsystem. In this example, the ASC system removes identifiable informationit receives from the emergency room device and stored this de-identifiedinformation, e.g., in the cloud. The ASC system also may remove theidentifying information, e.g., prior to presentation in a graph format.

In an example, a user (e.g., a patient) can set permissions for when/howto receive alerts. For example, a user may specify that he/she onlywants to receive alerts to a mobile device, or only wants to receivealerts that are authenticated, and so forth.

Referring to FIG. 11, graphical user interface 1100 enables a user tocombine files to generate a report that combines information fromvarious different sources. For example, a user can select to generate acombined report from a chart note (e.g., a medical note) and a medicaloutcomes note (e.g., information that specifies the outcome of one ormore medical procedures).

Referring to FIG. 12, graphical user interface 1200 displays a reporteditor that is used to edit and/or update a medical report and medicalsummary for a patient. The medical report is automatically generated bythe ASC system and can be manually edited, e.g., by editing the textdisplayed in text box 1206. In an example, the report is automaticallyupdated as the ASC system receives updated medical information, e.g., inreal-time from emergency room monitoring devices, from CCDA documentsand so forth. Graphical user interface 1200 displays synch information1202 specifying whether the information displayed in the report isup-to-date and synched with the information that is in the database.Graphical user interface 1200 also displays synch control 1204, selectof which causes the report to be re-synched with the database, e.g., tobe updated with new information from the database.

Referring to FIG. 13, graphical user interface 1300 displays anotherexample of the report editor. In this example, the information displayedin the report edit in unsynched with the database, as shown byinformation 1302. There are various ways in which information can beunsynched with a database. In some examples, a user manually edits thereport displayed in graphical user interface 1300, thereby causing thedisplayed report to be unsyched with the database. In this example, theuser selects control 1304 to cause the report to be synched with thedatabase, e.g., by updating the database with the information that isedited in the report. In another example, the report is unsynched withthe database when that database is updated with information and thatinformation is not yet displayed in the report. In this example,selection of control 1304 causes the report to be updated with theinformation that is saved in the database.

Referring to FIG. 14, networked environment 1400 allows for integrationof propriety medical information (e.g., answers to medical instrumentsand questionnaires, medical outcome information, and so forth) with CCDAinformation. The proprietary medical information and CCDA informationexist as primarily unique data that are not merged. The networkedenvironment 1400 also increases the safety of providing medical servicesto patients. For example, the networked environment 1400 enables a userto enter selection criteria to find (and filter) patients possessing thespecified criteria. The networked environments allows the filtered listof patients to be combined with outcome data (e.g., juxtaposed to eachother) to enable views to determine medical hypotheses. For example, auser can search for patients that regularly take albuterol (amedication) and search for patients that have a medical diagnosis ofdiabetes. In response, the system provides a filtered list of patientsthat take albuterol and have diabetes. Additionally, the system alsoprovides outcomes data for the patients included in this filtered list(e.g., information indicative of an outcome of talking albuterol). Byviewing the outcomes data with the filtered search results, a user ispresented with relevant information that may assist the user indetermining hypotheses (e.g., how albuterol affects diabetes).

Networked environment 1400 includes medical instrument system 1404,client device 1406, network 1408, CCDA system 1410, ASC system 1414, VPN1416, hospital device (e.g., emergency room device) 1418 and datarepository 1420. In this example, medical instrument system 1404comprises a system for storing various medical instruments (e.g.,medical questionnaires) and collecting patient responses to the medicalinstruments. The medical instrument system 1404 also stores informationindicative of patient satisfaction scores (e.g., when medicalinstruments pertain to satisfaction) and outcome date and outcome scores(e.g., when the medical instruments pertain to outcomes of medicalprocedures). In an example, the medical instrument system 1404 isfurther described in U.S. Pat. Nos. 8,429,547 and 8,630,870, the entirecontents of each of which are hereby incorporated by reference. In thisexample, medical instrument system 1404 sends, over network 1408,medical information 1422 to ASC system 1414. In this example, medicalinformation 1422 includes information indicative of answers and otherdata collected through medical instruments 1405. In this example,medical information 1422 includes the name of the name or otherinformation (e.g., a unique identified) that uniquely identifies thepatient.

ASC system 1414 includes a system for triaging the intake of a patient,e.g., by obtaining signatures for consent forms and waivers and byreconciling conflicting data (e.g., conflicts between data obtained froma CCDA system and medical information 1422). The ASC system 1414 alsoallows uses to electronically request and receive data, e.g., from CCDAsystem and from medical instrument system 1404. The ASC system 1414 alsocomplies with ASC rules that a physician can all patient information(e.g., whether it is from the medical instrument system 1404 or from theCCDA system 1410) but that staff are restricting in viewing of certaintypes of data. The ASC system 1414 implements these rules via ASC rules1424 (which are stored in data repository 1420). In an example, the ASCrules 1424 specify which portions of user data are viewable to whichmedical personnel, e.g., by specifying user IDs for various portion ofthe user data. Then, when a particular user goes to view data, ASCsystem 1414 executes the ASC rules 1424 to determine whether the user isassociated with an authenticated user ID for viewing of the data.

Networked environment 1400 also includes CCDA system 1410 for sending(e.g., via a HL7 feed) a CCDA record 1412 to ASC system 1414. The CCDAsystem 1410 is associated with a medical clinic or medical facility fora patient. Using the techniques described herein, the ASC system 1414 isconfigured to request the CCDA record.

In this example, ASC system 1414 stores CCDA record 1412 and medicalinformation 1422 as two separate data sets. ASC system 1414 associatesthe two separate data sets with each other by determining a matchingidentifier (e.g., a patient name, a patient unique identifier, and soforth) among the data sets and generates a pointer. The ASC system 1414also determines whether there is any conflicting information among thedata sets (e.g., the same data field with differing data values). Upondetection of a conflict, the ASC system 1414 prompts a user to enterinformation to resolve the conflict, as previously described.

Networked environment 1400 also includes ER device 1418 (e.g., a devicein an emergency room or in a hospital) that is configured forcommunication with ASC system 1414 via VPN 1416. In this example, ASCsystem 1414 receives real-time ER information 1426 from ER device 1418over VPN 1416. As previously described, the real-time ER information1426 enables the ASC system 1414 to display to a view the real-timemonitoring results during a medical procedure and also enable the ASCsystem 1414 to notify and alert users of predefined events (e.g., amonitored value exceeds a threshold value) in real-time and over anon-private network (e.g., network 1408). This provides a viewer withaccess to ER information. In this example, data repository 1420 alsostores information indicative of pre-defined alerts and triggers andrules specifying one or more devices and users to alert, e.g., upondetection of a triggering event. In this example, upon detection of atriggering event, the ASC system 1414 sends to client device 1406 anotification message to alert a user of client device 1406 of thetriggering event.

The ASC system 1414 also associates the real-time ER information 1426with the CCDA record 1412, for a particular patient, and with medicalinformation 1422 for a particular patient. The ASC system 1414 does thisdetecting a match among identifying information (e.g., a patient name, apatient identifier, and so forth) in the CCDA record 1412, the medicalinformation 1422 and the real-time ER information. In an example, ASCsystem 1414 collects thousands and millions of items of medicalinformation 1422 from medical instrument system 1404 and thousands andmillions of CCDA records from CCDA system 1410. Therefore, the memoryand processing devices in ASC system 1414 are able to efficientlybuffer, process and parse these millions of medical records to quicklygenerate the necessary associations between them. In the example of FIG.14, ASC system 1414 generates data for graphical user interface 1402that presents a side-by-side view of outcomes data (e.g., from medicalinformation 1422) and CCDA data 1412.

In this example, a patient schedules an appoint for a medical procedurewith ASC 1403. ER device 1418 is located inside ASC 1403. The requestfor the appointment may come from within another medical facility (e.g.,CCDA system). When the other medical facility submits the request andschedules the outpatient surgery with the ASC 1403, the other medicalfacility submits the patient's medical records (e.g., CCDA record 1412)to ASC system 1414. Through this submission, ASC system 1414 promotesclosing the gap of the surgery center when the patient is admitted.

Additionally, as previously described, ASC system 1414 performsreconciliation mitigation to ensure that the data (e.g., the CCDA dataand the medical information) is synchronous and non-conflicting.Additionally, ASC system 1414 allows for real-time feedback that issecure, encrypted and HIPPA compliant, e.g., by the editing of themedical notes and by receiving the real-time ER information 1426 from ERdevice 1418. Additionally, when a triggering event is detected, ASCsystem alerts all users (e.g., doctors, nurses, and so forth) of thetriggering event. The ASC system 1414 is also customizable in that auser can specify which types of information they want to view in acustomizable report. The user can also define which events aretriggering events (e.g., when a patient's blood pressure exceeds athreshold value).

In an example, data repository 1420 also stores notification rules 1425,e.g., information specifying when to contact users and how to contactusers. In an example, ER device 1418 sends to ASC system 1414 monitoringinformation (e.g., blood pressure information). In this example,notification rules 1425 includes a rule then when blood pressureinformation exceeds a threshold value to alert the patient's mother,father and best friend, in addition to alerting the treating physician.A device of the treating physician made be connected to VPN 1416. Assuch the treating physician may be able to receive the notification overthe VPN 1416. However, the devices of the mother, father and best friendare not connected to the VPN 1416 of the ER and/or of ASC 1403.Accordingly, the transmission of the real-time ER information 1426 overVPN 1416 to ASC system 1414 allows the ASC system 1414 to store thereal-time ER information in the cloud (e.g., in data repository 1420)and to notify family members and friends, who are otherwise unable to benotified due to their lack of connectivity to the VPN 1416.

In an example, ASC system 1414 is located outside of ASC 1403. Inanother example, ASC system 1414 is located inside of ASC 1403. In avariation, ASC system 1414 includes medical instrument system 1404.

In an example, ASC system 1414 transforms the CCDA record 1412 andmedical information 1422 into an ASC electronic medical record (e.g., anASC EMR 1413). ASC system 1414 performs the transformation by generatinga new data record for the patient. This new data record includesdemographic information that is obtained from medical information 1422and/or is obtained from a system input. The data record also includesoutcomes information, satisfaction information and answers to medicalinstruments, as included in medical information 1422. The reconciliationprocess updates conflicting information in either CCDA record 1412 or inmedical information 1422, such that information is reconciled. ASCsystem 1414 completes the transformation by attaching the CCDA record1412 (e.g., with reconciled data) to the newly generated records. Aspreviously described, data is reconciled by prompting a user to entervalid information (e.g., for a particular data field with conflictingvalues) and updating the data field with the entered information. ASCsystem 1414 performs the attachment by generating a database pointerfrom the CCDA record 1412 to the medical information 1422. Additionally,federal and/or various state governments may regulate ASC EMRs, e.g., byprecluding them from including certain types of information, byrequiring that information be encrypted according to specified formats,by requiring that the information be HIPPA compliant, by requiring thatcertain types of information be “scrubbed” to remove identifyinginformation, as shown in the below Table 2:

TABLE 2 Federal Regulation Rule Electronic health records Enabledrug-drug and drug-allergy checks on (EHR) meet required EMR measuresregarding Drug-drug and Drug-allergy Checks Electronic health recordsRecord patient diagnoses for more than 80% (EHR) meet required ofpatients objectives regarding Problem List Medication Allergy ListRecord patient medications for more than 80% Electronic Exchange IProvider send a summary of care record for more than 50% of transitionsof care and referrals Electronic Exchange II A provider electronicallytransmit a summary of care for more than 10% of transitions of care andreferrals

As shown in the above Table 2, federal regulations have manyrequirements, e.g., EMRs (or EHRs) must enable drug-drug anddrug-allergy checks, EMRs must record patient diagnoses for more than80% of patients, and so forth. In this example, ASC system 1414transforms the resulting ASC EMR by executing a rules engine thatincludes thousands of rules (such as the ones shown in the above Table2) against the resultant ASC EMRs (e.g., thousands of ASC EMRs). Forexample, ASC system 1414 determines whether the resultant ASC EMRsrecord patient diagnoses for more than 80% of patients (e.g., 80% of thegenerated ASC EMRs). If the ASC system 1414 determines that the rule issatisfied, ASC system 1414 moves on to analysis of the next rule. Whenthe ASC system 1414 determines that the rule is not satisfied, the ASCsystem updates the underlying data records for the ASC EMRs with therequired information (e.g., update additional ASC EMRs with patientdiagnosis information).

Other federal regulations mandate the actual use cases of electronicinformation exchange. In this example, a rule requires that a providersend a summary of care record for more than 50% of transitions of careand referrals and another rules requires that the providerelectronically transmit a summary of care for more than 10% oftransitions of care and referrals. In this example, the ASC system 1414also executes these electronic exchange rules and if it determines thata requirement is not satisfied generates the required electronicexchanges (e.g., generates a summary of care record and sends to apatient or medical provider). Generally, the regulations for ASC EMRsdiffer from those for EMRs generally, given the different nature ofASCs—which prevent overnight stays. Therefore, an ASC EMR is differentfrom other EMRs (e.g., EMRs for a hospital or an emergency room) becausethe ASC EMR may only include information for the ASC in combination withother CCDA information and perhaps other health care information for apatient. In still another example, given the different governmentregulations, the ASC EMR is separate and distinct from other types ofEMRs that are regulated by different, other government rules. Bygenerating an ASC EMR, ASC system enhances patient safety and qualityoutcomes. The ASC EMR provides extensive amounts of clinical data thatreveal trends and outcomes easily missed in paper charts. An ASC EMRalso greatly reduces errors by standardizing processes, while electronicflags and alerts warn staff of missing steps and other factors thatcould possibly harm the patient. An ASC EMR also benefits patients afterthey have left the ASC. An ASC EMR ensures that at the time the patientis discharged, all their records are complete and timely. The ASC alsoincreases operating room (OR) efficiency, because the charts (such asthose previously shown) are right in front of the surgical team; they'reable to chart quickly, efficiently and everyone is able to read it.

EMR in a surgery center is very different from EMR in a physician'soffice. Since there are only a limited number of operations performed,steps like diagnosis and treatment, which are necessary for EMRs totrack in physicians' offices, may not be included an ASC based EMR.However, ASC system 1414 is able to integrate data records from numerousdifferent sources with real-time OR information (received over theprivate network) to generate a very powerful ASC EMR 1413, e.g., basedon the template based integration. Accordingly, integration with theCCDA record 1412 and the other medical information 1422 provides for avery comprehensive ASC EMR 1413, e.g., an ASC EMR that includesdiagnosis and treatment as specified in either CCDA record 1412 ormedical information 1422. An ASC-based EMR follows the process frompre-op through surgery and post-op, making sure safety and compliancerequirements are met. Additionally, the ASC system 1414 is able toachieve a high level of interoperability. It is difficult to sendinformation electronically from one EMR system to another, whether thesystem is in a hospital, physician's office or ASC. Even when bothsender and receiver have an EMR, information often must be faxed. Forexample, the physician's office faxes the patient's history and physicalto the ASC. In an example, this document is scanned into ASC system 1414and displayed as a PDF-style page. In another example, ASC system 1414is configured for electronic communication with CCDA system 1410, e.g.,to enable ASC system 1414 to electronically obtain CCDA record 1412. Inthis example, ASC system 1414 is able to integrate CCDA record 1412 withmedical information 1422 and with ASC-specific information (e.g.,real-time ER information 1426). In this example, CCDA system 1410 may bean EMR system.

In this example, ASC system 1414 is able to do the electronicintegration via a data feed into CCDA system 1410. ASC system 1414 alsoincludes a template for converting information in the CCDA record 1412to a format of the medical information 1422 and/or to a format of theASC EMR, as described in U.S. Ser. No. 12/774,694, the entire contentsof which are incorporated herein by reference. One of the difficultiesof EMR integration is that every EMR has different fields and formatthat it uses for the storage of data. The template described in U.S.Ser. No. 12/774,694 provides for EMR integration by pre-mapping fieldsin one type of EMR to fields in another EMR, in advance of run-timeintegration. For example, if ASC system is to be interoperable with aCCDA system 1410 (or another EMR system), the ASC system 1414 willgenerate template that provides a mapping between the field in the EMRfor the other EMR system and the fields in the ASC EMR 1413, e.g.,thereby enabling ASC system 1414 to import the information into the ASCEMR 1413. This template can also be used for converting the medicalinformation 1422 into a format of ASC EMR 1413, thereby integrating themedical records from different data sources and EMRs. The ASC EMR mayinclude ASC specific fields for pre-op information, surgery informationand post-op information. ASC system 1414 populates these fields of theASC EMR 1413 with information obtained from the OR device in the ASC.The ASC EMR 1413 may also include other fields that are unrelated to theASC, e.g., treatment and diagnosis fields. In this example, the templatespecifies which fields in the CCDA record 1412 or in the medicalinstrument data correspond to the treatment and diagnosis fields in theASC EMR 1413. Upon retrieving the CCDA record 1412 or the medicalinstrument data 1404, the ASC system 1414 identifies the treatment anddiagnosis fields in the CCDA record 1412 or the medical instrument data1404 and selects the information included in those fields. The ASCsystem 1414 then populates the treatment and diagnosis fields in the ASCEMR 1413 template with the selected information, e.g., by updatingfields in underlying database records with the selected information. Byintegrating the CCDA record 1412 and other EMR information with the ASCEMR 1413, the ASC EMR 1413 is able to provide surgeons and other medicalpersonnel in the ASC with a comprehensive view of the medical history ofa patient and with side-by-side analysis of OR data in comparison tooutcomes, satisfaction, treatment and diagnosis. That is, ASC system1414 is able to provide ASC personnel (such as surgeons) with areal-time view of the patient's health. This ASC EMR 1413 ensurescompliance by helping ASC quickly and easily access all informationrequested during accreditation, state and CMS surveys. The ASC EMR 1413also helps with clinical reporting and quality outcome requirements,e.g., by storing safe surgery checklists and by prompting team membersto checking off specific items on the checklist.

In an example, ASC EMR 1413 includes a specified format. In thisexample, using the template, ASC system 1414 converts the CCDA record1412, the medical information 1422 (that includes outcome informationand satisfaction information), and real-time ER information 1426 intothe format of ASC EMR 1413 to provide for an integrated ASC EMR 1413.The ASC EMR 1413 is transmittable to numerous devices to promotecontinuity of care, e.g., transmitting to a physician's office.

Referring to FIG. 15, client device 1406 and medical instrument system1404 can be any sort of computing devices capable of taking input from auser and communicating over network 1408 with system 1414 and/or withother client devices. For example, client device 1406 and medicalinstrument system 1404 can be mobile devices, desktop computers,laptops, cell phones, personal digital assistants (“PDAs”), servers,embedded computing systems, and so forth.

System 1414 can be any of a variety of computing devices capable ofreceiving data, such as a server, a distributed computing system, adesktop computer, a laptop, a cell phone, a rack-mounted server, and soforth. System 1414 may be a single server or a group of servers that areat a same location or at different locations.

The illustrated system 1414 can receive data from client device 1406,medical instrument system 1404 and ER device 1418 via input/output(“I/O”) interface 1450. I/O interface 1450 can be any type of interfacecapable of receiving data over a network, such as an Ethernet interface,a wireless networking interface, a fiber-optic networking interface, amodem, and so forth. System 1414 also includes a processing device 1454and memory 1452. A bus system 1456, including, for example, a data busand a motherboard, can be used to establish and to control datacommunication between the components of system 1414.

The illustrated processing device 1454 may include one or moremicroprocessors. Generally, processing device 1454 may include anyappropriate processor and/or logic that is capable of receiving andstoring data, and of communicating over a network (not shown). Memory1452 can include a hard drive and a random access memory storage device,such as a dynamic random access memory, or other types of non-transitorymachine-readable storage devices. Memory 1452 stores computer programs(not shown) that are executable by processing device 1454 to perform thetechniques described herein.

Referring to FIG. 16, ASC system 1414 performs process 1500 intransmitting OR information to individuals outside of the OR, in asecure, encrypted, HIPPA-compliant manner. In operation, ASC system 1414establishes (1502), over a private network in an ambulatory surgicalcenter (ASC), a communication channel between a medical device in theASC and an ASC integration system that is connected to the Internet,with the medical device being restricted to communication over theprivate network. ASC system 1414 receives (1504), by the establishedcommunication channel over the private network, real-time medicalinformation from the medical device, during performance of a surgicalprocedure at the ASC. ASC system 1414 applies (1506) one or morenotification rules to the received real-time medical information todetect the occurrence of a triggering event. ASC system 1414 determines(1508), from the one or more notification rules, one or more entities tocontact regarding the triggering event, with the one or more entitieshaving one or more devices that are unconnected to the private network.ASC system 1414 transmits (1510), over the Internet, one or morenotification messages to the one or more devices that are unconnected tothe private network.

Referring to FIG. 17, ASC system 1414 performs process 1700 intransforming collected medical data into an ASC EMR, e.g., by updatingand writing to underlying database records in a defined manner. Inoperation, ASC system 1414 transforms (1702) medical data into an ASCEMR by receiving, from an external device (e.g., at another EMR system,at a hospital, and so forth), a Consolidated Clinical DocumentArchitecture (CCDA) record that includes first medical information for apatient for whom the surgical procedure is being scheduled. ASC system1414 also receiving, from another external device (e.g., the medicalinstrument system), second medical information for the patient. ASCsystem 1414 detects a conflict between the first medical information andthe second medical information; and prompts a user for information toresolve the conflict.

ASC system 1414 also transforms (1702) the first and second medicalinformation into an ASC EMR by generating a data record that includesthe second medical information and attaching the generated data recordto the first medical record. ASC system 1414 integrates (1704) the CCDAdata and Medical Instrument Data with the ASC EMR to add diagnosis andtreatment information to the ASC EMR through template integration, aspreviously described. ASC system 1414 receives (1706), from anelectronic device in an operating room over a private network, real-timeoperating room information. ASC system 1414 adds (1708) the real-timeoperating room information to the ASC EMR. ASC system 1414 executes(1710) a rules engine against contents of ASC EMRs (e.g., millions ofASC EMRs) to determine whether the ASC EMRs comply with one or moregovernmental regulations for ASC EMRs. ASC system 1414 updates (1712)data base records for ASC EMRs to be in compliance to governmentalregulation rules, as previously described.

Embodiments can be implemented in digital electronic circuitry, or incomputer hardware, firmware, software, or in combinations thereof. Anapparatus can be implemented in a computer program product tangiblyembodied or stored in a machine-readable storage device for execution bya programmable processor; and method actions can be performed by aprogrammable processor executing a program of instructions to performfunctions by operating on input data and generating output. Theembodiments described herein, and other embodiments of the invention,can be implemented advantageously in one or more computer programs thatare executable on a programmable system including at least oneprogrammable processor coupled to receive data and instructions from,and to transmit data and instructions to, a data storage system, atleast one input device, and at least one output device. Each computerprogram can be implemented in a high-level procedural or object orientedprogramming language, or in assembly or machine language if desired; andin any case, the language can be a compiled or interpreted language.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read-only memory ora random-access memory or both. The essential elements of a computer area processor for executing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. Computer readablemedia for embodying computer program instructions and data include allforms of non-volatile memory, including by way of example semiconductormemory devices, e.g., EPROM, EEPROM, and flash memory devices; magneticdisks, e.g., internal hard disks or removable disks; magneto opticaldisks; and CD ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in special purpose logic circuitry. Anyof the foregoing can be supplemented by, or incorporated in, ASICs(application-specific integrated circuits).

To provide for interaction with a user, embodiments can be implementedon a computer having a display device, e.g., a LCD (liquid crystaldisplay) monitor, for displaying information to the user and a keyboardand a pointing device, e.g., a mouse or a trackball, by which the usercan provide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well; for example, feedbackprovided to the user can be any form of sensory feedback, e.g., visualfeedback, auditory feedback, or tactile feedback; and input from theuser can be received in any form, including acoustic, speech, or tactileinput.

Embodiments can be implemented in a computing system that includes aback end component, e.g., as a data server, or that includes amiddleware component, e.g., an application server, or that includes afront end component, e.g., a client computer having a graphical userinterface or a Web browser through which a user can interact with animplementation of embodiments, or any combination of such back end,middleware, or front end components. The components of the system can beinterconnected by any form or medium of digital data communication,e.g., a communication network. Examples of communication networksinclude a local area network (LAN) and a wide area network (WAN), e.g.,the Internet.

The system and method or parts thereof may use the “World Wide Web” (Webor WWW), which is that collection of servers on the Internet thatutilize the Hypertext Transfer Protocol (HTTP). HTTP is a knownapplication protocol that provides users access to resources, which maybe information in different formats such as text, graphics, images,sound, video, Hypertext Markup Language (HTML), as well as programs.Upon specification of a link by the user, the client computer makes aTCP/IP request to a Web server and receives information, which may beanother Web page that is formatted according to HTML. Users can alsoaccess other pages on the same or other servers by followinginstructions on the screen, entering certain data, or clicking onselected icons. It should also be noted that any type of selectiondevice known to those skilled in the art, such as check boxes, drop-downboxes, and the like, may be used for embodiments using web pages toallow a user to select options for a given component. Servers run on avariety of platforms, including UNIX machines, although other platforms,such as Windows 2000/2003, Windows NT, Sun, Linux, and Macintosh mayalso be used. Computer users can view information available on serversor networks on the Web through the use of browsing software, such asFirefox, Netscape Navigator, Microsoft Internet Explorer, or Mosaicbrowsers. The computing system can include clients and servers. A clientand server are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

Other embodiments are within the scope and spirit of the descriptionclaims. For example, due to the nature of software, functions describedabove can be implemented using software, hardware, firmware, hardwiring,or combinations of any of these. Features implementing functions mayalso be physically located at various positions, including beingdistributed such that portions of functions are implemented at differentphysical locations. The use of the term “a” herein and throughout theapplication is not used in a limiting manner and therefore is not meantto exclude a multiple meaning or a “one or more” meaning for the term“a.” Additionally, to the extent priority is claimed to a provisionalpatent application, it should be understood that the provisional patentapplication is not limiting but includes examples of how the techniquesdescribed herein may be implemented.

A number of exemplary embodiments of the invention have been described.Nevertheless, it will be understood by one of ordinary skill in the artthat various modifications may be made without departing from the spiritand scope of the invention.

What is claimed is:
 1. A computer-implemented method comprises: establishing, over a private network in an ambulatory surgical center (ASC), a communication channel between a medical device in the ASC and an ASC integration system that is connected to the Internet, with the medical device being restricted to communication over the private network; receiving, by the established communication channel over the private network, real-time medical information from the medical device, during performance of a surgical procedure at the ASC; applying one or more notification rules to the received real-time medical information to detect the occurrence of a triggering event; determining, from the one or more notification rules, one or more entities to contact regarding the triggering event, with the one or more entities having one or more devices that are unconnected to the private network; and transmitting, by the ASC system over the Internet, one or more notification messages to the one or more devices that are unconnected to the private network.
 2. The computer-implemented method of claim 1, further comprising: receiving, from an external device, a request to schedule the surgical procedure with the ASC; receiving, from the external device, a Consolidated Clinical Document Architecture (CCDA) record that includes first medical information for a patient for whom the surgical procedure is being scheduled; receiving, from another external device, second medical information for the patient; detecting a conflict between the first medical information and the second medical information; and prompting a user for information to resolve the conflict.
 3. The computer-implemented method of claim 2, further comprising: transforming the first and second medical information into an ASC EMR by generating a data record that includes the second medical information and attaching the generated data record to the first medical record; executing a rules engine against contents of ASC EMRs to determine whether the ASC EMRs comply with one or more governmental regulations for ASC EMRs; and receiving, from an electronic device in an operating room over a private network, real-time operating room information; and adding the real-time operating room information to the ASC EMR.
 4. The computer-implemented method of claim 2, wherein the second medical information is retrieved from a medical instrument system that is configured to administer one or medical instruments and collect results of those medical instruments.
 5. The computer-implemented method of claim 1, further comprising: generating information indicative of an appointment to perform the surgical procedure; and defining, for the appointment, one or more roles of service providers in the ASC with regards to the surgical procedure, with a role specifying one or more types of information that a particular type of service provider is responsible for inputting into the ASC system.
 6. The computer-implemented method of claim 4, further comprising: receiving information that is input to the system from a service provider assigned to a specific role, with the received information including a personal identification number; and confirming that the personal identification number matches an authorized personal identification number of a user who is authorized to perform the role and to input a type of information to be completed by an entity in the assigned role.
 7. The computer-implemented method of claim 1, further comprising: automatically triaging, by the ASC system, intake of a patient for whom the surgical procedure is performed by performing operations comprising: generating data for a graphical user interface that displays consent forms and medical information for the patient, with the medical information being collected from a plurality of different data sources.
 8. The computer-implemented method of claim 1, further comprising: synchronizing, by the ASC system, the real-time medical information with other medical information included in a data repository of the ASC system.
 9. The computer-implemented method of claim 7, wherein synchronizing comprises: updating a data record in the data repository with the real-time medical information.
 10. One or more machine-readable hardware storage devices storing instructions that are executable by one or more processing devices to perform operations comprising: establishing, over a private network in an ambulatory surgical center (ASC), a communication channel between a medical device in the ASC and an ASC integration system that is connected to the Internet, with the medical device being restricted to communication over the private network; receiving, by the established communication channel over the private network, real-time medical information from the medical device, during performance of a surgical procedure at the ASC; applying one or more notification rules to the received real-time medical information to detect the occurrence of a triggering event; determining, from the one or more notification rules, one or more entities to contact regarding the triggering event, with the one or more entities having one or more devices that are unconnected to the private network; and transmitting, by the ASC system over the Internet, one or more notification messages to the one or more devices that are unconnected to the private network.
 11. The one or more machine-readable hardware storage devices of claim 10, wherein the operations further comprise: receiving, from an external device, a request to schedule the surgical procedure with the ASC; receiving, from the external device, a Consolidated Clinical Document Architecture (CCDA) record that includes first medical information for a patient for whom the surgical procedure is being scheduled; receiving, from another external device, second medical information for the patient; detecting a conflict between the first medical information and the second medical information; and prompting a user for information to resolve the conflict.
 12. The one or more machine-readable hardware storage devices of claim 11, wherein the operations further comprise: transforming the first and second medical information into an ASC EMR by generating a data record that includes the second medical information and attaching the generated data record to the first medical record; executing a rules engine against contents of ASC EMRs to determine whether the ASC EMRs comply with one or more governmental regulations for ASC EMRs; and receiving, from an electronic device in an operating room over a private network, real-time operating room information; and adding the real-time operating room information to the ASC EMR.
 13. The one or more machine-readable hardware storage devices of claim 11, wherein the second medical information is retrieved from a medical instrument system that is configured to administer one or medical instruments and collect results of those medical instruments.
 14. The one or more machine-readable hardware storage devices of claim 10, wherein the operations further comprise: generating information indicative of an appointment to perform the surgical procedure; and defining, for the appointment, one or more roles of service providers in the ASC with regards to the surgical procedure, with a role specifying one or more types of information that a particular type of service provider is responsible for inputting into the ASC system.
 15. The one or more machine-readable hardware storage devices of claim 14, wherein the operations further comprise: receiving information that is input to the system from a service provider assigned to a specific role, with the received information including a personal identification number; and confirming that the personal identification number matches an authorized personal identification number of a user who is authorized to perform the role and to input a type of information to be completed by an entity in the assigned role.
 16. The one or more machine-readable hardware storage devices of claim 10, wherein the operations further comprise: automatically triaging, by the ASC system, intake of a patient for whom the surgical procedure is performed by performing operations comprising: generating data for a graphical user interface that displays consent forms and medical information for the patient, with the medical information being collected from a plurality of different data sources.
 17. The one or more machine-readable hardware storage devices of claim 10, wherein the operations further comprise: synchronizing, by the ASC system, the real-time medical information with other medical information included in a data repository of the ASC system.
 18. The one or more machine-readable hardware storage devices of claim 17, wherein synchronizing comprises: updating a data record in the data repository with the real-time medical information.
 19. An electronic system comprising: one or more processing devices; and one or more machine-readable hardware storage devices storing instructions that are executable by one or more processing devices to perform operations comprising: establishing, over a private network in an ambulatory surgical center (ASC), a communication channel between a medical device in the ASC and an ASC integration system that is connected to the Internet, with the medical device being restricted to communication over the private network; receiving, by the established communication channel over the private network, real-time medical information from the medical device, during performance of a surgical procedure at the ASC; applying one or more notification rules to the received real-time medical information to detect the occurrence of a triggering event; determining, from the one or more notification rules, one or more entities to contact regarding the triggering event, with the one or more entities having one or more devices that are unconnected to the private network; and transmitting, by the ASC system over the Internet, one or more notification messages to the one or more devices that are unconnected to the private network. 